AGGREGATE, & GENERATED Additional notes.

Got a very good questions from someone who read my article about MANUALLY CONFIGURED ROUTES: “What is the purpose of using discard with a generated route?”

I didn’t think much about it at first. I mean, traffic coming in that matches the generated route, but not any of the specific routes, would be discarded instead of forwarded using a default route for example, or the next-hop of the primary contributing route as it would happen if you didn’t configure the discard option.

But, then I thought: “wait, then what is the difference between configuring discard for a generated route or for an aggregate route?”.

I checked the outputs of the show route protocol aggregate after configuring, first an aggregate route, and then a generated route, both using the discard option. I noticed two things that I thought were worth writing about as an follow up to my previous article:

1) For generated routes, local and direct routes are not considered contributing routes.

This one makes perfect sense when you think about it. Local and direct routes have no next-hop, and generated routes inherit the next-hop from the contributing routes.

You can see the difference below:

2) When distributing generated into BGP, the router does not add the aggregator and the Aggregate set attributes.

Let’s look at this example now:

Routers in AS300 are receiving BGP updates from AS100 and AS200, advertising subnets 172.16.0/20 and 172.16.16/20 respectively.

R5 has to summarize these two prefixes before advertising the information to R6.

We need to create either an aggregate or a generated route, and then redistribute it into BGP.

BTW. Let me show you what happens if you try to configure both at the same time:

Not allowed!  We cannot have an aggregate and a generated route for the same prefix.

So, let’s try the aggregate route first:

The aggregate has been created:

Looking at the details:

I highlighted two important details in the output:

• The AS path which shows 100 and 200 between { } which indicates an AS set, as defined in https://tools.ietf.org/html/rfc4271#section-5.1.6 and
• The (LocalAgg) flag.

Right now the router is advertising the two subnets, so let’s configure a policy to advertise only the summary:

You can see how the AS PATH contains the AS-SET that we described earlier and the LocalAgg flag.

Let’s take a look at the route at the receiving side:

You can see the AGGREGATOR attribute was added, and again the AS-PATH includes the AS-SET. 

As a result, R6 knows that R5 (192.168.5.5 in AS 300) aggregated routes within 172.16/19, and that the contributing routes for this aggregate came from AS 100 and AS 200. This will be used to avoid loops, even though the specific routes were not propagated. Very useful information!

We now changed from aggregate to generated:

And we check that the generated route was added to R5’s routing table, and that R5 is advertising the route to R6:

You can see that the AS-SET and the flag are missing!!!

No AS-SET is added to the route!

R6 has NO idea that this route came from an aggregate, and that the specific routes came from AS 100 and AS200.

I am sure you would agree with me that this is a significant difference between the two options!!!

aggregated routes generated routes